The present invention is in the field of methods and devices for digital processors and processor cores. More specifically, the present invention is directed to an enhanced processor that maintains backwards compatibility with a number of.earlier designs in the same family, including earlier processors with different address space and data widths.
A large literature exists regarding the history of processor development and evolution. A brief summary of this history is presented below. The reader is referred to infopad.eecs.berkeley.edu/CIC /archive/cpu_history.html and its cited documents for more information.
While processors have evolved dramatically over the last several decades, in many design applications and environments there remains an extensive interest in utilizing mature processor designs. Older designs have the advantage of a well-designed tool set, a large base of engineering expertise and familiarity, and in some cases a large investment in software code.
The Z-80 processor is one older processor design in which there remains a large interest. The Z-80 was originally developed to be a successor to the Intel 8080 and was regarded at the time as a vast improvement. Like the 8080, the Z-80 used 8 bit data and 16 bit addressing. The Z-80 could execute all of the 8080 instructions and included 80 additional instructions (1, 4, 8 and 16 bit operations and block move and block I/O). The register set was doubled from the 8080, with two banks of data registers (including A and F) that could be switched between. This allowed fast operating system or interrupt context switches. The Z-80 also added two index registers (IX and IY) and 2 types of relocatable vectored interrupts (direct or via the 8-bit I register). Aspects of the Z80 are described in U.S. patent application No. 4,332,008.
One characteristic that made the Z-80 popular in designs was the memory interfacexe2x80x94the CPU generated its own RAM refresh signals, which meant easier design and lower system cost, the deciding factor in its selection for the Radio Shack TRS-80 Model 1, introduced on Aug. 3, 1977.
Like many processors, the Z-80 featured many undocumented instructions. In some cases, they were a by-product of early designs (which did not trap invalid op codes, but tried to interpret them as best they could), and in other cases chip area near the edge was used for added instructions, but fabrication made the failure rate high. Instructions that often failed were not documented, increasing chip yield. Later fabrication made these more reliable.
After its introduced, many variants of the Z-80 were developed and produced by a variety of manufacturers. A number of these processors were sold with peripheral components included on-chip. More recently, Z80 family processors are developed and distributed as soft-core specifications in a register transfer language (RTL), which can then be combined with other components to produce ASICs.
Hitachi produced the 64180 (1984) with added components (two 16 bit timers, two DMA controllers, three serial ports, and a segmented MMU mapping a 20 bit (1M) address space to any three variable sized segments in the 16 bit (64K) Z-80 memory map).
Zilog produced the Z-180, compatible with Z-80 peripheral chips, plus variants (Z-181, Z-182). The Z-280 was a 16 bit version introduced about July, 1987, with a paged (like Z-180) 24 bit (16M) MMU (8 or 16 bit bus resizing), user/supervisor modes and features for multitasking, a 256 byte (4-way) cache, 4 channel DMA, and a large number of new op codes added (total of almost 3,500, including previously undocumented Z-80 instructions).
A 16/32 bit Z-380 version also exists (1994) with an added 32-bit linear addressing mode that is not Z-80 compatible.
Z380
Another addition to the Z80 family is the Z380. While the Z380 was intended as an advanced 32-bit version of the Z80, with 16 Mb linear addressing, the processor had mixed results. One problem was that Z80 binary code could not run on the 380 without recompiling, therefore Z380 systems were not xe2x80x9cturn-keyxe2x80x9d compatible with software written for the Z80. A further difficulty is that the Z380 mechanisms for extending the capabilities of the Z80 and Z180, while maintaining binary program compatibility, were inconvenient for both assembly-language programmers and C compiler writers, and expanded the code space requirements for both kinds of programs. The Z380""s multi-byte op-code prefixes meant that every time a 24- or 32-bit address or data value was used in an instruction, the instruction not only had to extend by the necessary 8 or 16 bits, but by another 16 bits of xe2x80x9cDDIR prefixxe2x80x9d as well. This has proved to be linear addressing and wider data at too high a price in code size.
Despite all the further developments made in mP design since 1977, there remains continuing interest in Z80-based processing. For many computer control applications, Z80 processing remains a versatile, reliable and inexpensive solution. As a result of this continued interest, a substantial body of tools and support components for the Z80, including emulators, compilers, etc. continues to be distributed. See, for example, the resources listed at www.geocities.com/SiliconValley/Peaks/3938/z80_home.htm.
Zilog, Inc., continues to produce a sell a number processors in the Z80 family. A brief comparison of the features of these processors is presented in the table below. Further information is available at http://www.zilog.com/resources/ z80r.html.
Memory Management
An important enhancement in processor design is the ability to address a large address space. The address space is determined by the number of bits the processor can manipulate and output as an address
Most 8 bit processors are limited to addressing 64k of memory, using two 8-bit words to address each memory location. A 16 bit CPU generally can support 1 to 16 Mb of memory. To support these larger address spaces, the processes generally utilize a memory management unit (MMU) to access an address space larger than 64k, but still maintain compatibility with earlier instruction sets. Under one MMU scheme, all instructions, in all modes, issue 16 bit addresses. The MMU converts these 16 bit addresses to 20 bits.
In such a scheme, physical memory generally refers to the entire universe of memory addressible by the processor. The memory that can be addressed with any one map, or configuration, of the MMU is called the logical address space. In this scheme, every address generated by a user""s program is a logical address and the MMU""s role is to translate these logical addresses into physical ones. On power up, the MMU may translate every logical address to exactiy the same physical address (which simulates the Z80).
In an MMU scheme, address references made by a program is passed through the MMU before being presented to the physical memory space. If the address matches a range previously programmed into the MMU, then the MMU will add an offset to that address, forming the physical address.
Exd Z80
A number of years ago, Zilog purchased the exclusive rights to the Exd Z80 softcore. One advantage of the ExdZ80 was its single clock bus cycles. As implemented and marketed, the core was xe2x80x9cpurexe2x80x9d Z80, even including hidden Z80 instructions from 1975.
While the Z180 family has long advertised 20-bit address capability, its mechanism for achieving this, called the Memory Management Unit or MMU, is difficult to use and has impeded the use of this family into larger-scale applications. One would like to add a 24-bit mode in which the processor automatically fetches longer addresses and data, so that no prefix is required for most instructions.
What is needed is a processor xe2x80x9cbetweenxe2x80x9d the Z18x and Z38x families, that provides 24-bit linear addressing, is more natural and convenient to program than the MMU or 380, and allows more compact programs than the 380.
The present invention is a controller for executing instructions. A controller according to the invention may exist in a wide variety of embodiments, including, but not limited to, an integrated circuit, a part of an integrated circuit, a xe2x80x9csoft-corexe2x80x9d RTL descriptor language module, etc.
In one specific embodiment, a controller according to the invention is designed to maximize compatibility with Z80 and 18x applications at the binary level, while simultaneously minimizing code space and maximizing programming convenience for upgrades and new applications that utilize 24-bit operation.
According to a further embodiment, an instruction set for a controller is basically that of the Z18x family, with some optional new facilities to enable 24-bit addresses and data and further provides a Z80 derivative with 24-bit linear addressing and 24-bit ALU, but an external 8-bit data path.
In a further embodiment, the present invention provides a mP or mP core with multiple modes of memory addressing. These modes are designed to allow for backwards compatibility with legacy processor code. According to the present invention, these modes can operationally coexist, with processes written for different modes sharing the processor under control of a supervising or kernel process.
In a specific embodiment, these modes consist of at least five key modes, which may may be referred to as:
Note that while specific memory address space sizes are given above, the invention may in other embodiments have different memory space sizes.
In one specific embodiment, the invention can include an autonomous Multiply/Accumulator Engine (MAC). This engine is optimized to perform sum-of-products (SOP) operations with little CPU overhead, making the invention capable of more effectively handling a number of processing tasks, particularly tasks related to digitalsignal processing (DSP).
A further understanding of the invention can be had from the detailed discussion of specific embodiments below. For purposes of clarity, this discussion refers to devices, methods, and concepts in terms of specific examples. However, the method of the present invention may operate within a variety of types of logical devices. It is therefore intended that the invention not be limited except as provided in the attached claims.
Furthermore, it is well knowvn in the art that logic systems can include a wide variety of different components and different functions in a modular fashion. Different embodiments of a system can include different mixtures of elements and functions and may group various functions as parts of various elements. For purposes of clarity, the invention is described in terms of systems that include many different innovative components and innovative combinations of components. No inference should be taken to limit the invention to combinations containing all of the innovative components listed in any illustrative embodiment in this specification.
All publications, patents, and patent applications cited or listed herein are hereby incorporated by reference in their entirety for all purposes. The invention will be better understood with reference to the following drawings and detailed description.
FIG. 1 is a block diagram of a processor according to an embodiment of the invention.
FIG. 2 is a block diagram showing pinout of an example processor according to an embodiment of the invention.
FIG. 3 (Table 1) indicates operation of CALL Instruction according to an embodiment of the invention.
FIGS. 4, 4A, 4B (Table 2) indicate operation of RST et al according to an embodiment of the invention.
FIG. 5 (Table 3) indicates which prefix selection affects each (class of) instruction according to an embodiment of the invention.
FIG. 6 (Table 4) indicates register loading to enable a MAC status according to an embodiment of the invention.
FIG. 7 (Table 5) indicates bits indicating MAC status according to an embodiment of the invention.
FIG. 8 (Table 6) indicates State of IEF1 and IEF2 according to an embodiment of the invention.
FIGS. 9, 9A, 9B (Table 7) indicate Processor and Device Pin Descriptions according to an embodiment of the invention.
FIG. 10 (Table 8) indicates Common Base Register (0038H) CBR according to an embodiment of the invention.
FIG. 11 (Table 9) indicates Bank Base Register (0039H) BBR according to an embodiment of the invention.
FIG. 12 (Table 10) indicates Common/Bank Area Register (003AH) CBAR according to an embodiment of the invention.
FIG. 13 (Table 11) indicates Load Instructions according to an embodiment of the invention.
FIG. 14 (Table 12) indicates Arithmetic Instructions according to an embodiment of the invention.
FIG. 15 (Table 13) indicates Logical Instructions according to an embodiment of the invention.
FIG. 16 (Table 14) indicates Exchange Instructions according to an embodiment of the invention.
FIG. 17 (Table 15) indicates Program Control Instructions according to an embodiment of the invention.
FIG. 18 (Table 16) indicates Bit Manipulation Instructions according to an embodiment of the invention.
FIG. 19 (Table 17) indicates Block Transfer Instructions according to an embodiment of the invention.
FIG. 20 (Table 18) indicates Rotate and Shift Instructions according to an embodiment of the invention.
FIG. 21 (Table 19) indicates Input/Output Instructions according to an embodiment of the invention.
FIG. 22 (Table 20) indicates Processor Control Instructions according to an embodiment of the invention.
FIG. 23 (Table 21) indicates Flag Register according to an embodiment of the invention.
FIG. 24 (Table 22) indicates Flag Settings Definitions according to an embodiment of the invention.
FIG. 25 (Table 23) indicates Condition Codes according to an embodiment of the invention.
FIGS. 26A, 26B (Table 24) indicate Instruction Summary according to an embodiment of the of the invention.
FIGS. 27, 27A-27L (Table 25) indicates Op Code Map (1st Op Code) according to an embodiment of the invention.
FIGS. 28A, 28A-1, 29A-2 (Table 26) indicates Op Code Map (1st Op Code) according to an embodiment of the invention.
FIG. 28B shows the organization of the table of FIG. 28A.
FIGS. 29A, 29A-1, 29A-2 (Table 27) indicate Op Code Map (2nd Op Code after OCBH) according to an embodiment of the invention.
FIG. 29B shows the organization of the table of FIG. 29A.
FIGS. 30A, 30A-1, 30A-2 (Table 28) indicate Op Code Map (2nd Op Code After ODDH) according to an embodiment of the invention.
FIG. 30B shows the organization of the table of FIG. 30A.
FIGS. 31A, 31A-1, 31A-2 (Table 29) indicate Op Code Map (2nd Op Code After OBDH) according to an embodiment of the invention.
FIG. 31B shows the organization of the table of FIG. 31A.
FIGS. 32A, 32A-1, 32A-2 (Table 30) indicate Op Code Map (2nd Op Code After 0FDH) according to an embodiment of the invention.
FIG. 32B shows the organization of the table of FIG. 32A.
FIG. 33A (Table 31) indicates Op Code Map (4th Byte, after 0DDH, 0CBH, and d) according to an embodiment of the invention.
FIG. 33B shows the organization of the table of FIG. 33A.
FIG. 34A (Table 32) indicates Op Code Map (4th Byte, after 0FDH, 0CBH, and d) according to an embodiment of the invention.
FIG. 34B shows the organization of the table of FIG. 34A